Chapitre 6. “PROcessus de Publications REproductibles” : de quoi s’agit-il exactement ?
6.1 Mise en place d’une démarche PROPRE au sein du datalab
6.1.1 Git, pièce maîtresse
Mettre en place un processus reproductible, c’est donc d’abord se poser la question de l’outil à choisir pour la gestion des versions du code source. Git (\ɡɪt\) est, à date, l’outil le plus utilisé pour ce faire. Il est devenu un incontournable du développement logiciel pour des projets informatiques de toute taille. En référence à la section précédente, dans son fonctionnement usuel, on installe git sur un serveur ainsi que sur les postes des utilisateurs. Un préalable en termes d’infrastructure est donc de disposer d’une part d’un serveur accessible aux utilisateurs ciblés et d’autre part des compétences et droits administrateurs système pour réaliser cette installation et le paramétrage ad hoc. En effet, le serveur et les utilisateurs échangent avec des protocoles de communication qui nécessite d’épouser la politique de sécurité de l’organisation qui met à disposition ce type de service. À l’instar de R et de son IDE RStudio, Git est souvent couplé avec un logiciel chargé d’assister, via une interface graphique, la gestion des projets git. Les trois principaux acteurs logiciels en la matière sont Gitlab, Github et Bitbucket. Chacun de ces fournisseurs propose une version installable (auto-hebergée) mais aussi des solutions clé en main du “logiciel en tant que service” (Software as a Service abrégé en SaaS) avec des modèles de prix et de confidentialité des données assez différents. Perception est faite ici que les choix à opérer sont liés au degré d’autonomie tant de la décision que des compétences par rapport à une infrastructure existante. Il n’est pas rare, dans le cadre de la construction de “laboratoires” de la donnée, de voir émerger ces outils séparémment de services et d’infrastructures existants sur des budgets dédiés. Le coeur de la forge maintenant implantée, cette dernière peut être peuplée du code qui constituera le capital logiciel de l’organisation. À l’instar de dossiers de travail partagés sur des espaces disque, il est possible de configurer des groupes d’utilisateurs avec des périmètres et des droits : ces derniers sont souvent le reflet des organisations des équipes.
Par contre, et cela est beaucoup moins fréquent pour des dossiers de travail propres à une organisation, il est aussi possible de configurer le gestionnaire de version de telle sorte à autoriser les développeurs à exposer certains projets sur Internet si l’intention est de publier des travaux en open source. Cependant, héberger soi-même ses projets publiés en open source sur internet n’est pas si fréquent pour deux raisons : la sécurité d’une part, la visibilité d’autre part. En effet, publier sur internet nécessite d’ouvrir des brèches dans les réseaux sur lesquels transitent et sont stockées les informations parfois sensibles des organisations, cela nécessite une bonne maîtrise des problématiques de sécurité et de maintenance. De telle forges sont aussi souvent accompagnées d’une authentique politique de diffusion engageant l’organisation dans sa gouvernance et sa communication.Avec 100 millions de projets accessibles sur Internet, GitHub est vraisemblablement la plateforme la plus prisée et visible pour publier du code open source.
En choisissant de publier du code open source, il est impératif et nécessaire en tout premier lieu de se poser la question des licences d’utilisation dudit code. Le droit français considère les développeurs salariés comme des auteurs et leur confère donc un droit moral perpétuel, inaliénable et imprescriptible sur le droit de divulgation et de paternité. Le code de la propriété intellectuelle les prive par contre du droit au respect et à l’intégrité de l’oeuvre ainsi qu’au droit de retrait et de repentir. Charge à l’employeur donc, du privé comme du public, de se préoccupper des droits patrimoniaux d’exploitation des projets proposés en open source et d’en définir les contours. Dans tous les cas, qu’ils soient open source ou pas, la diffusion de logiciels via la forge devrait toujours s’accompagner d’une licence pour leur utilisation. Il est également souhaitable de tenir d’autres éléments à disposition des utilisateurs dans une forge publique : un fichier de type “readme” (parfois traduit “lisezmoi”) qui explique comment utiliser le code, la maturité du projet… ainsi qu’un fichier de type “CoC” pour “Code de conduite” qui précise (si et) comment contribuer au projet selon des modalités définie par les auteurs et mainteneurs du projet.
6.1.2 Et c’est en foRgeant qu’on devient foRgeron
Le premier composant de l’usine installé, vient le temps de l’alimenter de code et de données. Comme vu en introduction, le langage de programmation choisi par le DREAL datalab est R pour son adéquation aux besoins et aux compétences existantes du datalab. Se pose alors la question du type d’installation et de la gestion des dépendances pour la mise en exploitation. Deux possibilités se profilent alors : R est installé localement sur chaque machine utilisateur ou R est un installé sur un serveur sur lequel les utilisateurs se connectent pour bénéficier du service. Dans un cas comme dans l’autre, le choix est loin d’être anodin et demande un examen attentif à l’aune de critères tels que la taille de l’équipe, son autonomie, sa dette technique, le code historique existant…
R, à l’image de nombreuses technologies open source, évolue vite : il sort une nouvelle version de R tous les 6 mois. Nul besoin de mettre à jour si fréquemment. Seulement, comme décrit en section 3.1, R est souvent (voire toujours) utilisé avec des packages (ces modules complémentaires qui fournissent des fonctionnalités additionnelles). Les packages sont en revanche mis à jour de façon continue.
Par ailleurs, certaines utilisations de R (notamment pour les SIG - systèmes d’information géographiques) nécessitent l’installations de dépendances systèmes. C’est à dire que certains packages tirent parti d’outils développés par ailleurs en open source, dans d’autres langages de programmation. Par exemple le package {sf} est un package R qui permet la lecture, l’écriture, la manipulation et le tracé de données spatiales vectorielles. À cet effet il repose sur des outils logiciels tels que GDAL, GEOS et PROJ qui doivent être installés sur la machine.
En proposant aux utilisateurs d’utiliser R (bien souvent en combinaison avec RStudio) sur serveur, les utilisateurs (ou les infogérants) sont épargnés d’une installation locale autant de fois qu’il y a de postes à configurer ou mettre à jour. Le cadre de travail proposé est alors unifié : les installations sont centralisées, les mises à jour sont contrôlées. Un recensement en amont de la primo-installation permet d’équiper la plateforme selon les besoins identifiés.
Ce type d’infrastructure nécessite souvent un profil de type “Administrateur R” doublé d’une politique de mise à jour. L’administrateur R ou, “R admin”, est un profil à même d’endosser des rôles de maintenance de serveur et qui dans le même temps a des connaissances en R et son fonctionnement. Cette personne applique et prodigue des conseils sur la politique de mise à jour qui dicte quand, comment et pour qui ou quels projets sont mises à jour les versions de R et les packages. En effet, il existe une infinité de nuances entre : une seule version de R et un “instantané” des packages nécessaires à l’exploitation pour tous les utilisateurs vs chacun peut installer tout ce qu’il souhaite dans son espace.
D’un côté du spectre, difficile de bénéficier de l’innovation en continue promise par l’open source si les utilisateurs sont bridés par une mise à jour annuelle ou, autre extrême, une mise à jour journalière qui pressurisera une maintenance de chaque instant sur tous les projets.
De l’autre côté, une grande liberté permise à chaque utilisateur risque de nuire à la mise en production et de creuser la dette technique. Un projet développé en 2015 avec R 3.2 et par exemple le package {dplyr} dans sa version 0.5 nécessitera des développements de maintenance pour être porté dans une version plus récente de R et {dplyr}. Or s’il est possible de faire fonctionner des projets dans des états antérieurs, il est crucial d’adresser cette problématique de maintenance et mise à jour sous peine de laisser du capital code en friche difficilement mobilisable en cas de besoin. Par exemple, pour faire face à l’augmentation de 1600 % de demandes d’indemnisation chômage relative à la pandémie de Sars-CoV-2 en avril 2020, (l’état du New-Jersey s’est activement mis à la recherche de développeurs COBOL pour mettre un jour des programmes vieux…d’une quarantaine d’années)[https://qz.com/1832988/covid-19-results-in-new-jersey-desperately-needing-cobol-coders/].
Dans un scénario où les utilisateurs sont maîtres de leurs propres installations en local sur leurs postes, cela signifie que les préoccupations du R admin sont déportées sur chacun des utilisateurs avec parfois des systèmes d’exploitations différents (voire même des dépendances systèmes différentes comme le navigateur web). Les utilisateurs doivent être autonomes sur leurs propres outils et bien comprendre les rouages de fonctionement de leur système d’exploitation, les outils qu’ils utilisent pour produire, les mécanismes d’installations sur leur machine ou encore savoir jongler entre deux bibliothèques de paquets pour deux installations de R. La politique de mise à jour doit se faire de façon coordonnée entre les utilisateurs sous peine d’observer des décalages trop importants entre les différents postes empêchant le bon fonctionnement des produits développés mais impactant également la productivité des utilisateurs. C’est le fameux “ça marche sur ma machine !”, d’autant plus source d’ennuis lorsque l’intervention sur la machine est compliquée par la distance dans le cas d’équipe distribuée géographiquement. Même si tous les utilisateurs utilisent la même forge git telle que décrite ci-avant, elle est “aveugle” pour l’instant aux fonctionnalités développées dans le code par ses utilisateurs. La forge git n’a pour rôle que de conserver le code source, pas de vérifier qu’il fonctionne.
Il serait difficile de construire un diagramme décisionnel qui objective et pondère les paramètres à prendre en compte pour arbitrer sur le choix d’une infrastructure locale ou serveur pour la brique R et ses dépendances mais la liste de questionnements ci-après peut guider la décision :
Quelle est la taille de l’équipe visée par le dispositif ?
L’équipe est-elle amenée à travailler de façon distancielle ?
Quel est son degré d’autonomie existant et/ou souhaité par rapport à l’outil ?
Quel est le taux de renouvellement de l’équipe ?
Combien de produits de data science sont mis en production par cette équipe ? Quelle fréquence de mise à jour envisagée ?
Y’a t’il une dimension réglementaire aux produits qui nécessite de figer des résultats à un instant donné à des fins d’audit ultérieures ?
6.1.3 Les outils modernes de publication de R
Une fois les moyens de programmer et de versionner déployés, il est opportun dans une équipe qui travaille ensemble de s’équiper d’un guide de “ses” bonnes pratiques. C’est-à-dire de se mettre d’accord collectivement sur les manières et méthodes de mettre en oeuvre le langage R en les documentant. L’intérêt de tels documents est de proposer des repères identiques pour l’ensemble des personnes amenées à intervenir sur des éléments du code afin de faciliter leur appropriation. Que ce soit pour sous-traiter ou pour intégrer de nouveaux membres dans une équipe, le guide des bonnes pratiques renseigne les parties prenantes sur la façon dont les solutions doivent êtres développées.
Rédiger dans R n’est pas aussi aisé que dans un traitement de texte mais s’en approche grâce à un langage de balisage dit léger appelé Markdown (cf 4.2). Les balises qui permettent de formater le texte sont visuellement peu encombrantes et permettent néanmoins une conversion aisée vers HTML pour les formats web, ou PDF pour des documents imprimés. Couplé à l’environnement de développement intégré RStudio, le rédacteur bénéficie de fonctionnalités telles que le rechercher-remplacer ou la correction orthographique. L’application en ligne Stackedit permet d’expérimenter et visualiser en temps réel le rendu fini d’un document édité avec Markdown pour mieux se familiariser avec les balises.
Plutôt plébiscité au début par une population de développeurs pour la documentation de leur code puisqu’il s’imbriquait bien avec du texte, le Markdown s’est fait une place dans nombre d’écrits numériques en remplacement des logiciels de traitement de texte.
Dans l’univers R, le paquet {rmarkdown} joue ce rôle d’imbrication du texte et du code. Et s’il était initialement utilisé pour documenter sous un format plus rédigé et plus long le mode d’emploi d’un package que la documentation unitaire des fonctions qui le composait (cf 4.6), son usage a glissé vers le reporting et la datavisualisation en outillant les utilisateurs avec des paquets de visualisation des graphiques et des tableaux qui soit dynamiques et interactifs. Un exemple de document développé avec {rmarkdown} par le DREAL datalab peut être visualisé à cette adresse.
L’autre outil de publication et de communication (voire d’aide à la décision) très populaire dans R est {shiny}. Tout comme {rmarkdown}, ce paquet permet de faire du web sans même sans rendre compte. {shiny} utilise des fonctions R pour d’un côté propulser les éléments visibles structurant la page destinée à être vue dans le navigateur et de l’autre orchestrer les calculs pour fournir à cette page les éléments visuels qui la composent (graphiques, tableaux, cartes…). Un atout notable de {shiny}comparé à des supports plus “statiques” tels que les RMarkdown est de permettre une palette importante d’interactions avec l’utilisateur (changer l’interface si tel événement, conditionner tel événement à un autre…). Un exemple d’application Shiny développée avec par le DREAL datalab peut être visualisé à cette adresse.
L’opportunité de développer une publication sur l’un ou l’autre outil doit s’évaluer à l’aune :
des compétences disponibles : Markdown étant un préalable à Shiny,
de la complexité des données sujettes à communication,
du degré d’interaction souhaité avec l’utilisateur.
Exposer une page “statique” produite avec RMarkdown n’est pas équivalent au déploiement d’une application Shiny en termes d’infrastructure mais dans les deux cas leur intégration dans un processus PROPRE sera facilitée par l’adoption du package comme standard de format.
6.1.4 Le package 📦 pour standard
Un package R est un dossier respectant un formalisme prédéfini qui contient des fonctions R et/ou des données. Un fichier de description recense les auteurs, la licence et les dépendances sur lesquelles reposent le paquet.
Dès lors qu’il contient une fonction ou un jeu de données, ces derniers doivent impérativement être documenté de façon individuelle (descriptif, paramètres à fournir, exemples minimums…).
Figure 6.1: Minimum viable pour un package ? - source : Diane Beldame
Sans ces points de contrôle, il n’est pas possible d’assembler un package pour qu’il soit installable sur une autre machine. Ainsi, par construction, un package favorise la compliance au versionnage, la factorisation et la documentation (mais aussi le respect du droit d’auteur et les droits d’exploitation). Formalisé ainsi, il devient “installable”, c’est à dire mobilisable ailleurs dans l’espace par d’autres utilisateurs mais aussi dans le temps car les dépendances sont connues et la documentation permet de s’immerger à nouveau dans le code avec plus d’aisance. C’est précisément ces propriétés qui sont recherchées lorsqu’on s’astreint à développer les analyses et applications R dans des packages.
Comme la documentation fonction par fonction n’explicite pas vraiment l’utilisabilité du package, c’est en mobilisant un outil comme {rmarkdown} qu’il est possible d’inclure de la documentation dans un format plus rédigé qui mêle du code (executé ou non) et du texte dans une vignette (cf 6.1.3).
Figure 6.2: Package avec une documentation dans un format long - source : Diane Beldame
Un package peut donc tout à fait contenir une analyse de données en faisant une large place au contenu éditorial.
Et parce que c’est un package, ce dernier peut bénéficier de l’assortiment de méthodes évoquées en section 4 : il devient testable, intégrable (cf 4.7) et éventuellement conteneurisable (cf 4.8).
Figure 6.3: Package avec une documentation dans un format long - source : Diane Beldame
User et abuser des packages est au coeur de la démarche PROPRE car en respectant le principe de séparation des préoccupations (cf 4.9), la forge s’équipe doucement de :
packages outils : ils contiennent des fonctions outils identifiées comme dénominateurs communs entre les projets
packages de données : ils peuvent héberger en leur sein des données et comme ils sont sujets au versionnage ils en assurent la traçabilité
packages d’analyse : ils dépendent des fonctions outils communes et des packages de données, il hébergent leurs propres fonctions internes et mettent en oeuvre les analyses en se préoccupant du fond
package de mise en forme : il dépendent des packages d’analyses et se chargent de la forme des rendus des packages d’analyse
Ensemble, ces paquets forment une tuyauterie optimale pour un passage de témoin sans friction aux outils d’intégration. Ces derniers se chargeront, de façon reproductible, d’assembler les éléments nécessaires au déploiement de chacun des produits. À la moindre anomalie, les tests mis en place signalent rapidement des dysfonctionnements : ils permettent les analyses d’impacts de mise à jour ou de nouveaux développements dictés par les besoins utilisateurs. C’est l’esprit DevOps mis en musique par le prisme des packages R.
Détecter l’opportunité de réaliser un package doit faire l’objet d’une concertation dans l’équipe mettant en oeuvre la démarche PROPRE, car si multiplier les projets est encouragé, c’est aussi multiplier la maintenance et… la dispersion des connaissances, rendant ainsi plus difficile l’appréhension des outils à dispositions dans la forge pour mener à bien sa mission.
Une ligne de conduite pourrait être :
dès lors qu’un fragment de code est copié-collé pour être réutilisé ailleurs, il fait l’objet d’une factorisation,
toute factorisation fait l’objet d’une mise en package,
toute fonction trouvée en dénominateur commun de plus d’un projet fera l’objet d’un projet séparé.
Seulement, ces principes n’indiquent pas exactement comment grouper des fonctions ensemble pour en faire un tout. Le degré de fragmentation en briques constitutives que sont les packages est donc très lié au métier et aux besoins. Le plus difficile étant de mutualiser suffisamment les connaissances pour ne pas fabriquer d’outils en double ou légèrement différents afin de bénéficier de l’effet de rationnalisation de la démarche.
6.1.5 Organisation et communication
La mise en oeuvre rigoureuse d’un dispositif technique tel que celui évoqué dans la section précédente ne dispense pas les parties prenantes d’échanges et de communication. Au-delà des réunions synchrones (qu’elles soient réalisées en présentiel ou distanciel), il est intéressant de disposer de solutions de communication asynchrones qui font la part belle aux intégrations avec les produits de la forge et sont plus pratiques que des serveurs de fichiers ou des boîtes aux lettres électroniques. Les solutions de communication collaboratives sont nombreuses et disposent de fonctionnalités variées telles que la gestion de projets, les compteur de temps, le partage de fichier ou de calendrier, les diagrammes de Gantt…
Dans le cadre de la démarche PROPRE, les outils devront permettre la mise en place d’actions du type “if
si un nouveau projet est créé dans la forge, créer un répertoire dans l’espace collaboratif et y intégrer les développeurs dans la forge
si des tests échouent dans la forge, envoyer un mail aux développeurs du projet
collecter les messages qui seraient envoyés depuis un formulaire dédié dans une application en production
programmer un robot qui rappelle régulièrement aux collaborateurs de prendre soin de leur posture de travail pour limiter les troubles musculo-squelettiques
programmer un robot qui réagit à un mot-clef donné pour diffuser de l’information
Ces outils viennent en complément des méthodes de type agile et de design thinking déjà adoptées par le DREAL datalab.
6.2 Une définition du processus de publication reproductible pour le DREAL datalab
Les promesses de la mise en oeuvre du PROPRE sont vertueuses :
Efficacité
Fiabilité
Résilience
Sécurité
Rationalisation
Valorisation
Amélioration
Transmission
Innovation
mais elles se monnayent au prix de la conduite du changement, d’efforts plus important pour la maintenance et la qualité ainsi que d’un changement de paradigme vers plus de polyvalence des parties prenantes.
En résumé, la démarche PROPRE ce serait…
une suite d’outils et de process, documentés, versionnés, testés, intégrés et automatisés à des fins de rationalisation adossée à une organisation flexible qui repose sur l’autonomie, la sécurité et la valorisation d’acteurs compétents qui la mettent en oeuvre avec comme langage de dialogue la brique fonctionnelle qu’est le package R
La prochaine étape vers la mise en oeuvre du PROPRE est la conduite d’un projet inter-DREAL d’un cas d’école grandeur nature sur les publications du répertoire des logements locatifs des bailleurs sociaux. Si le canal de communication des équipes en charge du développement n’est pas exposé au public, les travaux sont visibles sur le dépôt de code du Réseau de la Donnée et des Études Statistiques DREAL (https://gitlab.com/rdes_dreal/propre.rpls)